Security policies are often based on the concept of least privilege. Least privilege is directed to a client having the minimal access permissions necessary to accomplish required actions and nothing more. Any permissions that have been granted that are not needed to perform a correct function can be abused and or exploited and therefore should not be present. For example, a grant of too few permissions to a client charged with maintenance of a web server may prevent the client from performing essential functions, such as a server restart upon crash. In another example, a grant of too many permissions may allow a client charged with maintenance to make changes that may benefit the web server but break supporting systems, such as a change of static IP address. These additional permissions increase risk if the client's credentials are stolen or used improperly while providing no value.
However, implementing least privilege can be difficult. Client capabilities may not match authorized actions. Performing actions on a first resource may also require permissions to access a second or third resource. For example, a virtual machine may have access to block storage. A system charged with maintenance of the virtual machine may also need permission to clone and attach the block storage. However, in other cases, it may only be believed that access to a secondary resource is necessary, when it is not. Furthermore, client capabilities are not always static. Clients can become more capable or efficient over time, which may include a need for revisiting the security policies for each client. While various techniques have been employed to effectively prepare privilege policies, due to the complexity of the actions, the employed techniques are of varied success.